1. Field of the Present Invention
The present invention is generally related to the field of data processing networks and more particularly to the recovery of network information and, more specifically, network address information following a loss of data.
2. History of Related Art
In the field of data processing networks, the use of network addresses to identify various devices attached to the network is well known. The Dynamic Host Configuration Protocol (DHCP) is a communications protocol that facilitates the management and assignment of Internet Protocol (IP) addresses in an organization""s network. Using the Internet Protocol, each machine that can connect to an IP supported network needs a unique IP address. When a data processing device connects to the network, it must be assigned an IP address. Without DHCP, the IP address of each device would have to be entered manually. If a device were moved to another location in the network, a new IP address would have to be entered. DHCP lets a network administrator supervise and distribute IP addresses from a central point and automatically sends a new IP address when a device is plugged into a different place in the network. IP is documented in the Internet Engineering Task Force (IETF) Request for Comment (RFC) 791 while the existing DHCP specification is documented in RFCs 2131 and 2132, all of which are incorporated by reference herein.
DHCP uses the concept of a xe2x80x9cleasexe2x80x9d or amount of time that a given IP address will be valid for a client. The lease time can vary depending on how long a user is likely to require the IP address at a particular location. The lease concept is useful in environments where users change frequently. Using short leases, DHCP can dynamically reconfigure networks in which there are more clients than there are available IP addresses.
In a conventional network environment using DHCP to manage its IP addresses, one or more DHCP servers do the actual assignment and tracking of IP addresses. Each DHCP server maintains and uses a database containing IP address information. If this database is corrupted, the administrator will typically restart the DHCP server without the IP address state database, which can result in the following scenario.
Imagine that a first client, (Client A) on the network was assigned an IP address with a relatively long lease before the DHCP database became corrupted. Because the lease was not close to expiring, Client A will not have issued a renewal request for the IP address. After the DHCP server restart, a second client, Client B, issues a DHCP Discover packet to initiate the process of acquiring an IP address. The DHCP server may try to issue Client B the same IP address as Client A (because the server is no longer aware that the IP address was assigned to Client A). Before doing so, however, the DHCP server will xe2x80x9cpingxe2x80x9d the appropriate IP address to see if there is a device currently assigned to the address. Because the DHCP sever assigned Client A the IP address of interest before the IP address state database crash, the ping will generate a response. Upon receiving the response, the DHCP server will update the IP address state database to indicate that the IP address has a status of BAD, meaning that the address is unavailable and that it was assigned by another server. This status is incorrect since the address was assigned by the DHCP server. Thus, the conventional method of recovering from a corrupted IP address state database results in a database that does not accurately reflect the state of the network. It would therefore be desirable to implement a method and system to recover from an IP address state database crash that produced a more accurate database following recovery.
The problems identified above are in large part addressed by a method and system in which a DHCP server executes a recovery routine upon discovering a corrupted IP address state database. One embodiment of the invention complies with the existing DHCP protocol while a second embodiment extends the protocol to support a server initiated, DHCP-specific query. The recovery routine may attempt to determine whether an IP address is assigned to a DHCP client by sending a packet to a particular port at the IP address where the port is generally reserved for DHCP client processes. Depending upon the response that the packet generates, the server can determine whether a DHCP client is present at the IP address and can update the database accordingly.
In an embodiment that complies with the existing protocol, the query may comprise simply sending a TCP/IP packet to the appropriate IP address and port and monitoring for an Internet Control Message Protocol (ICMP) error message. If an ICMP error message results, the server assumes that the process at the address and port is not a DHCP client. The lack of an ICMP error message would suggest the presence of a DHCP client. In either event, the server can update the IP address state database accordingly.
In an embodiment that extends the existing DHCP protocol, the DHCP server issues a DHCP supported query to each IP address that responds to a ping command. The DHCP clients supporting this protocol extension will respond to the query by returning all of the DHCP configuration information that was assigned before the IP address state database crashed. In this manner, the IP address state database can be recovered. In either case, the IP address state database that is created following restart includes information that is more accurate than the information conventionally generated after a database crash in which it is assumed that all IP addresses responding to a ping command are bad.